Losing  Something  In  Translation 

Turning  Requirements  Into  Specifications 

Charles  M.  Court,  Ph.D. 

Perhaps  the  reader  remembers  the  comedy  routine  in  which  a  performer  orates  a  lyrical, 
emotive  passage  in  a  deep,  inspiring  voice— except  the  quotation  is  in  some  unintelligible 
language.  Another  performer  asks,  "What  does  that  mean  in  English?"  The  translation  is 
something  like,  "The  snake  fell  out  of  the  tree,  onto  the  baby  and  ate  him."  As  audience 
members  gasp  in  revulsion,  they  hear  the  punchline,  "It  loses  something  in  translation." 

Requirements  managers,  program  managers  and  warfighters  also  gasp  in  revulsion  after  engineering  teams  trans¬ 
late  requirements  into  specifications.  Sometimes  something  gets  lost.  More  often,  requirements  turn  into  exten¬ 
sive  and  expensive  specifications.  The  program  managers  decry  "requirements  creep”  while  the  requirements 


Court  is  the  Requirements  Center  Director  at  the  Defense  Acquisition  University's  Defense  Systems  Management  College  at  Fort  Belvoir  in 
Virginia.  He  is  a  former  Wild  Weasel  Electronic  Warfare  Officer,  a  test  manager,  a  program  manager,  and  an  Air  Force  laboratory  supervisor. 
His  doctorate  from  Walden  University  specialized  in  Organizational  Behavior. 


:nse  AT&L:  May-June  2016 


managers— representing  the  warfighter— wonder  what 
went  wrong  with  their  clear,  specific  and  necessary  op¬ 
erational  requirements. 

From  Analysis  to  Requirement 
to  Specification 

Remember  how  everything  starts  with  analysis.  The 
Capabilities-Based  Assessment  starts  with  directives, 
policy  changes  and  reports  from  the  field  to  determine 
what  the  warfighter  must  be  able  to  do.  The  assessment 
prioritizes  the  support  and  materiel  for  the  warfighter, 
and  the  requirements  managers  write  the  appropriate 
documents.  If  nothing  else  fills  a  capability  gap,  require¬ 
ments  managers  must  make  a  case  to  develop  some¬ 
thing  new. 

Ideally,  the  requirements  managers  write  the  mini¬ 
mum  number  of  measurable,  unambiguous,  results- 
oriented  operational  requirements.  Every  acquisi¬ 


tion  team  member  can  read  those  requirements  and 
immediately  agree  on  how  to  meet  them.  Unfortu¬ 
nately,  this  is  not  an  ideal  world.  Unfortunately,  the 
reality  of  what  is  possible  turns  clear  goals  into  com¬ 
plicated  systems,  subsystems  and  components.  This 
amounts  to  an  "explosion"  of  technical  requirements 
and  specifications  after  the  initial  validation  of  the 
operational  requirements. 

These  technical  requirements  and  derived  technical 
specifications  provide  the  details  necessary  to  develop, 
design,  manufacture,  test  and  support  the  hardware 
behind  a  military  capability.  For  example,  a  validated 
operational  requirement  may  lead  to  developing  a  new 
tracked  vehicle.  Top-level  operational  requirements 
may  lead  to  a  technical  requirement  for  treads  neces¬ 
sary  to  transit  areas  with  low  traction.  Since  U.S.  forces 
have  a  worldwide  mission,  the  operational  requirement 
may  lead  to  derived  technical  specifications  such  as 
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A  Partial  List  of  Different  Types 
of  Requirements 


Affordability 

Funding 

Reporting 

Allocated 

Information 

Resource 

Analysis 

Information 

service  (with  a 

Bureaucratic 

Systems 

small  "s") 

Capability 

Logistics 

Stakeholder 

Compliance 

Milestone 

Stated 

Contractual 

Mission 

Statutory 

Cost 

Operational 

Strategic 

Customer 

Performance 

Support 

Data 

Phase 

Sustainment 

Derived 

Physical 

System 

Design 

Program 

System-specific 

Documentation 

Programmatic 

Technical 

Functional 

Regulatory 

Testing 

What  Is  a  “Requirement?” 

Part  of  the  confusion  comes  from  disagreement  over  the  very 
word  "requirement."  Too  often,  a  reader  must  use  the  context 
to  determine  whether  a  document  is  about  capability  require¬ 
ments,  strategic  requirements,  technical  requirements  or  any 
of  the  other  requirements  in  the  partial  list  below. 

For  the  sake  of  clarity,  the  two  documents  behind  the 
Joint  Capabilities  Integration  and  Development  System 
(J  Cl  DS) — the  Chairman,  Joint  Chief  of  Staff  Instruction  (CJCSi) 
3170.01  and  the  JCIDS  Manual— do  not  use  the  single  word 
"requirement"  but  consistently  define  and  apply  the  term 
"capability  requirement."  Both  sources  define  capability 
requirement  as  "A  capability  which  is  required  to  meet  an 
organization's  roles,  functions,  and  missions  in  current  or 
future  operations." 

All  Requirements  Are  Created  Equal — 

Then  It  Gets  Complicated 


tread  width  calculated  on  maximum  allowable  ground  pres¬ 
sure  for  the  worst-case  operational  terrain. 

The  process  of  progressing  from  high-level  operational  re¬ 
quirements  to  technical  requirements  to  component  speci¬ 
fications  looks  something  like  the  illustration  from  a  recent 
Government  Accountability  Office  (GAO)  report  (Figure  1). 

While  supporting  the  warfighter  is  of  overriding  impor¬ 
tance,  meeting  the  warfighters'  needs  becomes  compli¬ 
cated  and  expensive  in  the  translation  from  system  to 
subsystem  to  component. 


Figure  1.  How  Operational  Requirements  Become 
Component  Specifications 
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Once  the  requirements  managers  document  the  capability 
requirements,  the  translation  to  specifications  begins.  Part 
of  the  loss  in  translation  comes  from  the  need  for  technical 
specificity  and  clarity.  For  example,  the  International  Council 
on  Systems  Engineering  (INCOSE)  Handbook  has  a  more  rigor¬ 
ous  definition  of  a  requirement:  "A  statement  that  identifies  a 
system,  product,  or  process  characteristic  or  constraint,  which 
is  unambiguous,  clear,  unique,  consistent,  stand-alone  (not 
grouped),  and  verifiable,  and  is  deemed  necessary  to  stake¬ 
holder  acceptability." 

The  confusion  over  terminology  is  exacerbated  further  by 
confusing  requirements  with  specifications.  Requirements 
managers  at  the  top  of  the  pyramid 
apply  their  operational  experience  to 
draft  the  "high-level"  operational  re¬ 
quirements.  Systems  engineers  turn 
those  operational  requirements  into 
technical  requirements  for  the  subsys¬ 
tems  and  into  specifications  for  each 
component.  This  means  both  require¬ 
ments  managers  and  systems  engi¬ 
neers  write  statements  called  require¬ 
ments.  To  many  program  managers 
and  program  offices,  anything  called 
a  requirement  becomes  non-negotia- 
ble.  Failingto  meet  any  requirement  is 
unacceptable.  The  program  office  and 
the  developing  contractor  will  do  their 
best  to  meet  any  and  every  require¬ 
ment,  whatever  its  source. 


Low-level 

requirements 


Source:  Government  Accountability  Office  report,  Defense  Acquisition  Process— analysis  of 
DoD  policy  and  guidance/ GAO  15-469,  June  2015. 


One  saving  advantage  is  the  flexibil¬ 
ity  the  Pentagon  leadership  had  built 
into  JCIDS.  First,  not  every  opera¬ 
tional  requirement  has  the  very  high¬ 
est  priority.  Once  the  requirements 
managers  develop  the  operational 
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requirements  for  a  proposed  new  system,  the  managers  tri¬ 
age  those  requirements  into  three  priority  levels:  Key  Per¬ 
formance  Parameters  (KPPs),  Key  System  Attributes  (KSAs) 
and  Additional  Performance  Attributes  (APAs).  See  Figure  2. 

The  JCIDS  Manual  defines  KPPs  as:  "Performance  attributes 
of  a  system  considered  critical  or  essential  to  the  develop¬ 
ment  of  an  effective  military  capability."  Originally,  failure  to 
meet  a  KPP  meant  that  the  Department  of  Defense  (DoD) 
would  cancel  the  program.  Declaring  a  requirement  a  KPP  was 
tantamount  to  saying,  "If  the  new  system  cannot  meet  this 
requirement,  we  don't  want  it  at  all.  We  will  keep  what  we  have 
now."  This  standard  has  softened  to  the  point  that  a  failure 
to  meet  a  validated  KPP  will  trigger  a  review.  This  validation 
authority  review  may  lead  to  program  cancellation,  but  it  may 
also  result  in  the  modification  of  production  increments  or  in 
an  updated  KPP  value. 

The  authority  that  validated  the  KPP  can  modify  the  KPP.  For 
an  Acquisition  Category  I  program,  the  validation  authority 
is  the  Joint  Requirements  Oversight  Council  (JROC)  chaired 
by  the  Vice  Chairman  of  the  Joint  Chiefs  of  Staff.  Managers 
approach  the  JROC  with  great  trepidation,  but  Pentagon  lead¬ 
ership  strives  to  show  the  flexibility  that  requirements  manag¬ 
ers  and  program  managers  need  in  order  to  make  necessary 
modifications  and  trade-offs. 

KSAs  are  one  step  below  KPPs.  The  JCIDS  Manual  defines 
KSAs  as,  "Performance  attributes  of  a  system  considered 
important  to  achieving  a  balanced  solution/approach  to  a 
system,  but  not  critical  enough  to  be  designated  a  KPP.”  A 
sponsor  at  the  level  of  a  four-star  officer  or  an  Agency  Direc¬ 
tor  can  modify  a  KSA. 

The  APAs  offer  more  opportunity  to  make  trade-offs  as 
the  requirements  managers  and  the  program  offices  apply 


lessons  learned  during  system  development.  APAs  are 
performance  attributes  of  a  system  that  are  not  important 
enough  to  be  considered  KPPs  or  KSAs  but  still  appropriate 
for  inclusion  in  requirements  documents  such  as  the  Ca¬ 
pability  Development  Document  (CDD)  and  the  Capability 
Production  Document  (CPD). 

One  remaining  area  of  confusion  involves  the  difference  be¬ 
tween  threshold  and  objective  values.  The  threshold  value 
is  the  minimum  value  that  will  have  operational  utility.  In 
other  words,  a  threshold  may  be  the  minimum  range  or 
payload  that  the  warfighter  will  find  useful.  The  objective 
is  either  the  maximum  parameter  or  the  maximum  feasible 
parameter  that  offers  operational  utility.  Anything  beyond 
the  objective  is  beyond  what  the  user  will  need.  Capability 
beyond  the  objective  amounts  to  the  "gold  plating"  every¬ 
one  wants  to  avoid. 

Recurring  Inconsistencies 

Remember  that  KPPs,  KSAs  and  APAs  all  represent  capability 
requirements.  When  the  systems  engineers  develop  technical 
requirements,  the  sheer  number  of  those  technical  require¬ 
ments  can  become  overwhelming. 

High-level  requirements— capability  requirements  derived 
from  analysis  and  developed  by  requirements  managers  with 
operational  experience— lead  to  many  low-level  requirements 
such  as  technical  requirements  and  specifications.  Congress 
decries  this  "requirements  explosion."  Program  managers 
scream  "requirements  creep."  All  the  warfighter  really  cares 
about  are  the  high-level  requirements,  the  capability  require¬ 
ments.  At  the  operational  level— when  guns  are  firing  and 
bombs  are  exploding  or  the  rocks  are  getting  too  close— the 
warfighter  does  not  have  time  to  care  about  the  technical  re¬ 
quirements  and  specifications.  The  overriding  goals  remain 
defeating  the  enemy  and  protecting  our  forces,  friendly  forces 
and  noncombatants. 


Figure  2.  The  Requirements  Hierarchy 
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The  challenge  becomes  knowing  when  to  make  essential,  ef¬ 
fective  trade-offs.  Here  is  where  program  management  and 
requirements  management  combine  into  a  contact  sport;  bad 
things  happen  when  each  specialization  works  in  isolation.  The 
requirements  manager— representing  the  warfighter— must 
work  with  the  systems  engineers  within  the  program  office. 
Managers  and  engineers  combine  their  knowledge  and  expe¬ 
rience  to  develop  appropriate  tradeoffs.  At  the  inception  and 
throughout  the  acquisition  phases,  all  parties  need  coherent 
answers  to  critical  questions  such  as: 

•  What  capability  does  the  warfighter  really  need? 

•  How  do  we  know  that  stated  need  is  valid? 

•  What  are  the  costs  and  associated  risks  associated  with 
meeting  a  threshold  or  an  objective? 

•  Can  we  deal  with  the  associated  costs  and  risks  of  missing 
a  threshold? 

•  What  is  the  nature  of  the  associated  costs? 

—Are  we  talking  about  money?  Delay?  Reliability? 
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•  Does  missing  a  threshold  really  degrade  the  military 
capability? 

•  What  are  the  payoffs  of  going  beyond  the  threshold  and 
achieving  the  objective? 

—What  are  the  risks  involved  in  going  beyond  the  thresh¬ 
old? 

•  What  do  the  ensuing  risks  mean  to  the  warfighter? 

•  Who  needs  to  validate  the  trade-offs? 

As  a  development  program  progresses  from  analysis  to  pro¬ 
duction,  many  people  have  opportunities  to  apply  the  lessons 
learned  from  the  Technology  Maturation  and  Risk  Reduction 
phase  and  the  Engineering  and  Manufacturing  Development 
phase.  These  lessons  learned,  for  example,  may  show  require¬ 
ments  managers  new  ways  to  apply  new  systems.  These 
lessons  also  may  help  the  systems  engineers  and  the  other 
technical  experts  understand  what  will  and  will  not  work  in  op¬ 
erational  environments.  Insight  into  the  concepts  of  operations 
can  guide  trade-offs  that  make  the  difference  between  a  good 
system  and  a  transformational  system— a  system  guarantee¬ 
ing  that  our  warfighters  prevail. 

The  Clash  of  Cultures 

The  DoD  has  excellent  reasons  to  combine  three  different 
management  systems  into  what  the  Defense  Acquisition  Uni¬ 
versity  calls  "Big  A  Acquisition."  JCIDS  represents  the  warf¬ 
ighter  and  develops  the  capability  requirements.  The  Defense 
Acquisition  System  turns  those  requirements  into  specifica¬ 
tions  and  strives  to  meet  those  specifications.  Planning,  Pro¬ 
gramming,  Budgeting,  and  Execution  lines  up  the  resources, 
includingfunding.  These  three  management  systems  operate 
with  different  schedules,  priorities  and  urgencies.  Successful 
programs  need  experienced  and  talented  management  to  keep 
the  three  systems  working  together. 

While  the  warfighter  first  cares  about  accomplishing  the  mis¬ 
sion,  the  engineers  and  the  rest  of  the  acquisition  community 
focus  on  how  to  accomplish  the  mission.  One  cultural  clash 
results  from  different  group  definitions  of  success.  Success  to 
the  acquisition  community  does  not  necessarily  mean  success 
to  the  warfighter.  Meeting  every  specification  does  not  guar¬ 
antee  operational  utility.  It  is  difficult  to  achieve  agreement 
between  the  different  viewpoints.  Here  is  where  requirements 
managers  and  program  managers  need  to  be  aware  of  the 
potential  breakdowns  that  can  arise  from  the  clash  between 
their  two  cultures.  Both  types  of  managers  should  anticipate 
additional  confusion  as  they  depend  on  the  technical  and  pro¬ 
fessional  expertise  of  diverse  professions  such  as  the  system 
engineers,  test  managers  and  logisticians. 

Solutions  From  Leadership,  Management 
and  Communications 

Everyone  can  agree  that  great  leadership  and  great  manage¬ 
ment  demand  great  communications.  We  cannot  afford  to 
waste  time  and  money  on  unnecessary  requirements  and 
specifications.  All  of  the  specialists  and  managers  live  with 
the  same  funding  limitations,  scheduling  priorities,  state  of 


technology  and  laws  of  physics.  Everyone  needs  to  recognize 
the  differences  between  capability  requirements  and  techni¬ 
cal  specifications.  In  the  ideal  situation,  everyone  agrees  on 
which  trade-offs  would  most  reasonably  help  accomplish  the 
mission  on  time  and  within  the  budget. 

It  isn't  easy  to  establish  and  maintain  communications  across 
the  different  groups.  Every  team  member  wants  to  do  a  great 
job  for  the  warfighter.  But  the  unintelligible  language  of  a  dif¬ 
ferent  professional  culture  and  the  confusion  from  different 
points  of  view  can  derail  the  best  intentions.  Requirements 
managers  have  a  responsibility  to  communicate  why  they  need 
the  requirements  that  they  write  and  validate.  Great  systems 
engineering  shows  a  clear  trail  from  the  high-level  capability 
requirement  to  the  technical  specifications.  Everyone  needs  to 
avoid  the  confusing  practice  of  calling  technical  specifications 
"low-level  requirements." 

Great  communication  takes  time,  effort  and  understand¬ 
ing.  To  that  end,  we  all  are  translators  who  cannot  afford 
to  lose  important  requirements  and  distinctions  in  transla¬ 
tion.  We  all  need  insight  into  the  DoD  processes,  into  the 
different  management  systems  within  "Big  A"  Acquisition, 
and  into  the  different  disciplines  that  are  needed  to  develop 
our  programs. 

Now,  is  that  a  carnivorous  snake  in  the  tree  or  a  colorful  rib¬ 
bon  floating  in  the  breeze?  Is  the  baby  being  eaten  alive  or  is 
he  simply  giggling  in  delight  over  a  harmless  new  toy?  The 
differences  are  significant.  In  the  same  vein,  we  must  work 
together  to  make  accurate  but  necessary  translations  as  we 
go  from  capability  requirements  to  technical  specifications 
and  then  to  operational  systems.  & 

The  author  can  be  contacted  at  charles.court@dau.mil. 


MDAP/MAIS  Program  Manager  Changes 


With  the  assistance  of  the  Office  of  the  Secretary  of 
Defense,  Defense  AT&L  magazine  publishes  the  names 
of  incoming  and  outgoing  program  managers  for  major 
defense  acquisition  programs  (MDAPs)  and  major  au¬ 
tomated  information  system  (MAIS)  programs.  This  an¬ 
nouncement  lists  the  only  such  change  of  leadership  for 
both  civilian  and  military  program  managers  reported  for 
the  months  of  January  and  February  2016. 

Air  Force 

Col  John  Newberry  relieved  Col  Christopher  Coombs 

as  program  manager  for  the  KC-46  Systems  program 
on  Feb.  8,  2016. 
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